Skip to main content

How to Use a Service Model

A service Model runs alongside all of the other Models in a Workflow. They are typically run as databases where other Models communicate with them to store ongoing information created during the Workflow.

A service Model will not start until the point where it is defined in the Workflow is reached and will then run until the end of the very end of the Workflow.

Creating a service Model​

You can create a service Model in the same way you would create a normal Model. But unlike a normal Model, you would design it so that it did not have an endpoint.

To declare a Model as a service you just need to set a flag in the service Model definition's metadata section:

  type: service

for instance:

kind: Model
api_version: v1beta3
metadata:
  display_name: Postgres database
  name: postgres-db
  type: service
  summary: A Postgres db service

Connecting to a service​

You will need to connect to a service Model from another Model. To do this you declare in the connecting Model the parameter you wish to receive the IP of the service Model. This parameter has a type of link and inside the Workflow will take the step-name you have given the service.

You specify a link parameter in a Model definition as follows:

spec:
  inputs:
    parameters:
      - name: THE_SERVICE_IP
        title: Service IP
        description: The IP of my service
        type: link

When you create your connecting Model you can use the name of the parameter as an environment variable in your code to connect to the service when required.

There is currently no limit on the number of Models that can connect to a service Model.

Adding a Readiness Probe​

If your service Model needs time to be setup before it can accept connections from another Model then you might need to add a readiness probe to ensure the service Model is ready. Databases are one example of a service Model that might need a readiness probe.

To make sure one is added to your Model you can add a resources section to the spec of the Model definition file for the service Model. Within this section add readiness_probe as below:

spec:
  resources:
    readiness_probe:
      host: POD_IP
      scheme: HTTP
      path: /health
      port: 5000

The host defaults to the IP address of the container that runs the service Model, this can usually be ignored for most service Models.

The scheme is the scheme to use for connecting to the container, defaults to HTTP can either be HTTP or HTTPS again this can usually be ignored for most service Models.

The path is the url to access the service Model at, this defaults to /. If this url does not respond at any point during the time the service Model runs then the Workflow running it will fail so choose a url that will be available throughout the service Models life.

The port is the port number to access the service Model at, this does not have a default value.

If you do not add a readiness_probe section then no readiness probe will be added.

Creating a Workflow​

Workflows with services in work in a similar way to other Workflows. But there are a few more things to remember.

You must make sure that the service is added as a step before any Models that require it are run.

In the parameters section of the Workflow you will have to specify the name of the service in any link parameters of connecting Models by the step-name you have given it in the current Workflow.

All services are automatically stopped at the end of the Workflow.

Example service Models​

There are two examples on our GitHub repository that show how to use a service Model and a client Model. You may want to check them out for more information:

  • service-example
    • A simple example of both a service Model and a normal Model communicating via ping.
  • service-example--database
    • An example of a database service Model and a client Model communicating with the database.